Add using and await using Declarations, SuppressedError, DisposableStack, and AsyncDisposableStack

[rbuckton]

This PR contains the Stage 3 specification text for Explicit Resource Management.

[rbuckton]

I'm not quite sure how to address the remaining esmeta issues.

[jmdyck]

Rather than suggest changes here, I've made a PR against this PR's branch: rbuckton#2

[rbuckton]

This last commit adds a few UpdateEmpty calls that aren't strictly necessary, but esmeta doesn't quite understand what's happening without it. I also had to switch AO parameters typed : a function object to : an ECMAScript language value since IsCallable doesn't seem to act as a type guard.

[bakkot]

@rbuckton Sorry about that - esmeta is still a little imprecise. You should feel free to write the spec text you want and not worry about esmeta's errors, and we can update esmeta or the ignore file.

[rbuckton]

@rbuckton Sorry about that - esmeta is still a little imprecise. You should feel free to write the spec text you want and not worry about esmeta's errors, and we can update esmeta or the ignore file.

I replaced the UpdateEmpty calls with a few asserts that seem to be accurate. For example, in ForIn/OfBodyEvaluation, if status is abrupt going in to DisposeResources, it should still be abrupt on the way out. Likewise, ForBodyEvaluation won't return a normal completion for empty, so DisposeResources shouldn't produce one either.

[rbuckton]

Please note, I've created rbuckton#3 as a separate PR against this one containing the additional specification changes that would be necessary to support https://github.com/tc39/proposal-async-explicit-resource-management, should it advance to Stage 3.

[rbuckton]

I found an issue with the change in e4f2d05 to use an EE to restrict binding patterns, in that it results in an ambiguous parse of using[x] before the EE can be applied, which was not intended.

I've filed tc39/proposal-explicit-resource-management#152 against the proposal spec, and will update this PR in due time.

[rbuckton]

I found an issue with the change in e4f2d05 to use an EE to restrict binding patterns, in that it results in an ambiguous parse of using[x] before the EE can be applied, which was not intended.

I've filed tc39/proposal-explicit-resource-management#152 against the proposal spec, and will update this PR in due time.

tc39/proposal-explicit-resource-management#152 has merged, and I've amended this PR to match as part of 3044fd9.

[syg]

@rbuckton What is an example of a using contained within a ClassBody? It can't be directly contained within one, and if indirectly contained, then it would already be directly contained within another production on the list (like ClassStaticBlockBody, FunctionBody, etc). During implementation we found the inclusion of ClassBody in this list confusing.

[rbuckton]

You are correct, ClassBody here is superfluous and should be removed.

[rbuckton]

This should be addressed by tc39/proposal-explicit-resource-management#220 and rbuckton#6

[rbuckton]

This now includes the await using declaration and AsyncDisposableStack, per prior consensus (incl. the March 2023 plenary).

[rbuckton]

Note to implementers: There is a typo in GetDisposeMethod that will be addressed by tc39/proposal-explicit-resource-management#217. The typo was introduced as part of a normative change that reached consensus in July 2023, but fixing it is also a potentially a normative change and may require additional consensus.

[rbuckton]

This is also missing the consensus change to use await using as the syntactic head for the asynchronous form of the using declaration. That will be up shortly.

[rbuckton]

25f1bc4 applies changes from the following PRs which previously achieved consensus in March 2023 and July 2023:

• Ignore return value of [Symbol.dispose]() method when hint is 'async-dispose' proposal-explicit-resource-management#180
• Move DisposeResources to Evaluation of FunctionStatementList proposal-explicit-resource-management#178
• Add missing calls to NewDisposeCapability AOs proposal-explicit-resource-management#175
• Correctly use hint in ForIn/OfBodyEvaluation proposal-explicit-resource-management#171
• Add missing .prototype property entries for DisposableStack/AsyncDisposableStack proposal-explicit-resource-management#167
• Merge async proposal back into sync proposal proposal-explicit-resource-management#154
• Revert 'await' restriction proposal-explicit-resource-management#153

[rbuckton]

Rebased (twice, to make GitHub happy). Hopefully that fixes the PR in the diff review website.

[debadree25]

Hey! now its significantly easier to read from https://arai-a.github.io/ecma262-compare/?pr=3000 thank you so much!!

[jmdyck]

More editorial suggestions at rbuckton#11

[rbuckton]

@bakkot, @syg, @michaelficarra: I am hoping to ask for Stage 4 at the May plenary, but this PR still requires reviews from the editors.

[bakkot]

@rbuckton Noted, we'll get to it ASAP. If we don't get to it before the meeting you're welcome to ask for stage 4 pending editor review, and then assuming the committee approves we'll land after we finish review.

[rbuckton]

@rbuckton Noted, we'll get to it ASAP. If we don't get to it before the meeting you're welcome to ask for stage 4 pending editor review, and then assuming the committee approves we'll land after we finish review.

Much appreciated. I'll look into addressing the two merge conflicts next week.

[sosukesuzuki]

I’m sorry if this has already been covered, but I was curious about one point during the implementation.

[sosukesuzuki]

Why do it only check for undefined and not isCallable?

[syg]

GetDisposeMethod calls GetMethod, which does a IsCallable check.

[sosukesuzuki]

I got it, thank you!

[bakkot]

The presence of the slot is checked a few lines below. We want to return a rejected promise in that case, following the principle that functions which return Promises should not synchronously throw.